1. Field of the Invention
The present invention relates to methods and apparatus for use in a push-to-talk type service, for example a so-called Push to talk Over Cellular service.
2. Description of the Related Art
Walkie-talkie type services have long proved popular amongst users who wish to communicate brief messages quickly between one another. Conventionally, such services have been provided by two-way portable radios which utilize a dedicated part of the radio spectrum, but which only allow users to communicate with a small group of pre-selected users who utilize similar terminals and who are within range of the relatively short operating range of the radios. More recently, services have been introduced into the United States which piggy-back on the existing cellular telephone infrastructure. However, these services have been proprietary in nature and have not allowed users to communicate between different operator networks.
In an attempt to broaden the use of walkie-talkie type services, an industry group known as the Open Mobile Alliance (www.openmobilealliance.org) has been established with the aim of standardizing suitable protocols which will allow inter-network operability for Walkie-Talkie services offered over cellular networks. The service established by the various standards is known as Push to talk Over Cellular (PoC). PoC proposes that associated speech data will be transported over a packet switched access network. In the case of GSM and UMTS, this packet switched access network will be the general packet radio service (GPRS) or 3G access network. In other network architectures, analogous packet switched access networks will be utilized for transporting talk data. Push-to-talk (PTT) services may also be offered over circuit switched access networks, although this is not the preferred option.
The Push to talk Over Cellular (PoC) system is typically implemented on GSM/GPRS/3G networks and makes use of the IP Multimedia Subsystem (IMS) standardized by the 3rd Generation Partnership Project to facilitate the introduction of advanced data services into cellular networks, particularly, real-time multimedia services. The IMS relies upon the Session Initiation Protocol (SIP) which has been defined by the Internet Engineering Task Force (IETF) for the setting up and control of multimedia IP-based sessions. A PoC Server is located within the IMS or is attached thereto, and implements the functionality for setting up and controlling PoC Sessions.
Existing push-to-talk (PTT) and conferencing systems typically use a control mechanism to grant one of the users the right to speak while other users in the communication are denied such right and are in listening mode. Such control mechanism is typically referred to by various synonymous terms such as “floor control,” “talker arbitration,” “talk burst control”, etc. For example, the Open Mobile Alliance (OMA) is currently working on a specification of Push to talk Over Cellular (PoC) system, which includes Talk Burst Control Protocol (TBCP).
To request the right to speak on behalf of the user, the terminal (PoC Client) typically sends a request message to the controller (PoC Server). The controller typically responds either granting or rejecting the request. The controller restricts the time the user is allowed to talk, typically by starting an allowed talk timer when it grants the request, and uses some mechanism to interrupt the user's talk, typically by sending a revoke talk message to the user's terminal or by simply not forwarding the user's media. The user who is interrupted by the controller is typically penalized by the controller in some way, e.g. by not granting the user the right to speak for a certain period of time.
The next version of OMA PoC (herein called “PoC 2”, with the previous version being called “PoC 1”) is evolving in OMA. Part of the planned functionality is to include new types of media such as pictures, video, etc., that can be shared within a PoC Session. Each media type shall have its own floor control. The following extract is from the OMA PoC 2 Requirement Document [OMA-RD-PoC-V2-0-20050902-D, Push to Talk Over Cellular 2 Requirements, Draft Version 2.0-02, September 2005]: “If a session includes video steams (and talk burst), the PoC infrastructure SHOULD support a capability to configure a preferred mode of video streaming on the PoC Client. This configuration may be done either: (a) due to the limitations of the PoC client (e.g. a PoC 1 client), configured by the Service Provider; or (b) configured by the user”. Also from the OMA PoC 2 Requirement Document: “The modes of sending video streams in conjunction with voice are: (i) Single source mode: Both PoC voice and PoC video comes from the same Participant in a PoC Session in near real time; and (ii) Multiple sources mode: PoC voice is sent from one Participant and PoC video is sent from another Participant in the same PoC Session”. Also from the OMA PoC 2 Requirement Document: “If the Media Burst Control is applicable for the media type the PoC network elements SHALL support capability for an independent Media Burst Control for each media in a PoC Session. Media Burst Control SHALL be applicable to all Continuous Media Types and SHOULD be applicable to the Discrete Media types involved in a PoC session. Note: Discrete Media types should only use Media Burst Control, if it is essential for the application using PoC enabler”. Also from the OMA PoC 2 Requirement Document: “If the Media Burst Control is applicable for the media type the PoC network elements SHALL support capability for one Media Burst Control for multiple media in a PoC Session”.
PoC 1 only has a monolithic floor control, i.e., for only one media type: the talk burst. PoC 2 expands the media handling to include other media types such as video. The PoC requirements state that there needs to be a mechanism that synchronizes the floor for different media so that it is possible for a user to send talk burst and video stream at the same time, as well as the opposite when one user sends the talk burst while another sends a video stream.
One possible approach to implementing multiple media burst control is illustrated in FIG. 1 of the accompanying drawings. FIG. 1 shows a PoC Client PC in communication with a PoC Server PS. In step P1, a Talk Burst Request for Voice media is sent from PoC Client PC to PoC Server PS. In step P2, a Talk Burst Request for a Video stream is sent from PoC Client PC to PoC Server PS. In step P3, the Talk Burst request for Voice media is denied or granted, with a message sent from PoC Server PS to PoC Client PC. In step P4, the Talk Burst request for Video stream is denied or granted, with a message sent from PoC Server PS to PoC Client PC.
However, the approach illustrated in FIG. 1 is not ideal because the floors are not coordinated and it may be that the user is not interested in a case where only one of the media types is granted.
Another problem with the existing solution in OMA PoC 1 is that when someone is granted the right to send a Talk Burst, the PoC Server is expecting the Talk Burst to be sent from the PoC Client that sent the Talk Burst request. Therefore, the PoC Server will discard any Talk Burst sent from any another PoC Client.
When introducing the possibility of sending pictures, video or any other media content, a PoC Client may request the floor for one media type on behalf of another PoC Client. For example, if the requesting PoC Client wishes to talk while another PoC Client will provide the picture, coordination of the floor is required between audio and the picture.
It is desirable to address the above-mentioned issues.